Websites, whether on the Internet, an intranet, or another network, typically contain a collection of resources providing information and services to users. The resources of the website may, for example, be represented by a group of web pages providing these information and services. The information and services may be accessed by a user via a browser using a unique Uniform Resource Locator (URL) for each resource. For a large website, the information and services may be presented by a large number of resources represented by many URLs. These resources may be divided over many machines or servers or logically divided into separate logical entities that have distinct, fully qualified domain names and possibly various directories or other structures within the domains.
Additionally, websites are constantly in flux as information and services are added, deleted, or relocated and the resources are moved within the service between machines, domains or directories. This presents a problem for maintaining links to the actual resources. Websites or software products that contain hard coded links indicating a full, qualified URL must be changed to maintain the links to the resources when the resources are moved. This is especially a problem for a website or software product that is likely to be updated somewhat infrequently.
A particular software product, such as a word processor, may have hard-coded links for help information or for downloads such as templates, clip-art, etc. When a user of the software product selects a hyperlink or other element indicating a URL, the software product launches a browser that retrieves information from the URL hard-coded in the application program. In other cases, the software product such as the word processor may be able to communicate using the Hyper-Text Transfer Protocol (HTTP). In such a case, the software product is able to retrieve the desired information directly, without launching a browser.
However, most software products are updated somewhat infrequently. For example, new versions of applications are updated via service packs or upgrades typically about once per year or even less frequently. New versions of software applications are typically supplied once per 2-3 years. Further, not all users upgrade with each release. So, contents of applications are largely fixed and will stay on a user's machine for long periods of time. However, relocation of the information to which hard-coded hyperlinks within the applications point may occur during the lifetime of the software product. Without an update of the hard-coded URLs in the software product, links to the information and services are broken.
Therefore, many websites and software products use link redirection. To use redirection a web resource or software product includes a hyperlink to a “redirector” which manages the actual location of the requested URL. Once a request for a URL is received by the redirector, the redirector is able to determine the actual final URL. The redirector sends back information repainting the requestor to use the correct URL. The browser or software product then sends another request for the correct URL using the received URL from the redirector.
Two types of redirector systems have been commonly used. One approach uses a database containing all possible redirect information indicating all varieties of locations for resources on the website or service. The database is then processed to produce a collection of code-scripted pages containing all the redirect data. These pages are then placed on the web site. A request for a URL from a user causes execution of code by the redirector to determine the correct URL from the URL list and return this result to the user in a redirection request.
Another common approach is to maintain a Structured Query Language (SQL) database with a record for each possible link and forcing every possible combination of desired parameters for that redirect to be maintained and queried against. This approach also utilizes a database of all possible redirect information indicating all varieties of locations for resources on the website or service. The redirector, upon receiving a request URL, executes code to construct and send a query to the database to retrieve results indicating the destination URL.
However, these systems suffers from a slow response resulting in a low number of transactions per second due to the need to search a potentially very large URL list or database for each request. In addition to poor performance, systems that utilize code to search a list of redirects are also hard to maintain since new code must be produced every time a URL changes. It is with respect to these and other considerations that the present invention has been made.